Skip to main content

Software Engineering at Google

Programming vs Software Engineering​

Lithmus test: If it clever is a complement its programming, if an accusation its software engineering Main difference is: Scaling and Time. How long do you expect code to live

Learnings​

Hyrum's Law: - With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. (anything you change will potentially break something with enough users)

  • Policies that doesn't scale well:
    • branching
    • interdependencies - what happened was in order to sped up their local development time, they started offsetting/outsourcing builds, as an effect people were not incentivise to monitor their local envs
  • Policies that scale well:
    • Beyonce rule - "if you like it put a CI test on it" Software Engineering Laws

Character Core Principles of Character​

  • Engineers are insecure by default

    • A common feature they asked was "how to hide code"
    • antithesis on the open floor seating as it starts prohibiting open communication, at the same time isolation is deadly as no one to bounce your ideas to.
      • Ways to communicate: 'Breakpoint Mary' - 'ack' if you are busy

  • Bus Factor - how many people needs to get hit by a bus before you project is doomed

  • Genius Myth - there is no one genius engineer, it is a team colllaboration (bill gates, Linus)

    • alot of your success will depend on how good you collaborate

  • Core Principles of Character:

    • Humility
    • Trust
    • Respect

  • Chesterton's fence - if you cannot determine/explain why a 'hack' is in place you have no right to refractor it

  • Zen Master - Be calm regardless of what happens, ask questions rather than panic

    • The higher place you are the bigger the wheel you are in the scheme of things, imagine the CEO being the biggest cog and all others chain to it as teeth, if the CEO panics, the smallest cog will spin out of control.

  • Ownership - codebases in google have BUILD files, where directories have a list of who own them.

  • BUS Factor -> how many people need to be hit by a bus before a project is doomed.

  • "Always be leaving, Always be Scaling, Always be Deciding"

Code Reiew​

  • Dont address the author but the code
  • In google, One LGTM (Looks Good to Me) is enough, all the other comments are left as to do
  • PTAL -> please take another look
  • Gerrit and critique
  • Automate code static analysis

Testing​

  • Test Sizes: Small Medium Large

    • Small -> one thread/process
    • Medium -> More than one thread but same machine
    • Large -> Multiple Machines

  • 1 % flakiness diminishes confidence in test suite, a workaround is retry flakey test programmatically if it cant be avoided. must be address though.

  • Test composition: 80% unit test, 15% integration test, 5% end-to-end (Chapter 11 Test Scope at Software Engineering at Google)

    • Anti Pattern -> Ice Cream Cone and the HourGlass Pattern
    • note on code coverage: software engineering at google page 222. the antipattern about focusing on code coverage
    • problem with integration test is the who one who writes the mocks are the ones who also write the unit test. so the mocks are assumptions. if the writer of the service provides their own mocks then assumptions are alleviated

Scaling and Search Engines​

  • N-Gram Array Suffix
  • Reverse Index